In the field of computer science garbage collection relates to a form of automatic management of memory resources. During execution of a computer operation(s) one or more computer objects can be created and data regarding those objects can be stored in a memory. Upon completion of a computer operation, the created object(s) may no longer be required, however, if an object(s) is still being referenced, resources associated with those objects, e.g., memory, cannot be reclaimed. In effect, until unwanted objects, or other unwanted items, become unreferenced, memory can be tied up rather than being freed and available for use to another operation. As further memory is tied down by subsequent computer operations and/or other functions, memory associated, with unwanted but still referenced items, can have a detrimental effect upon subsequent processing tasks, e.g., computer processing speeds are negatively impacted, application failure, thrashing of minimal computer resources, etc.
One particular computer environment of interest for garbage collection is the Microsoft .NET Framework which supports multiple programming languages in such a manner as to facilitate language interoperability. Code can be written in one language and access functionality implemented in another. One approach to the problem of memory management for applications running in the Microsoft .NET Framework is to monitor and control memory allocation on the “listener” side of an event. An event is an action that is usually initiated outside the scope of a current class. A typical event is where a mouse pointing device is being monitored to detect when a user clicks a button on the mouse, where the click is an event. An event handler can notify any listeners waiting (e.g., listening) for the event that the event has occurred. However, at the end of a process various listeners may no longer be interested in the event and accordingly, each listener is to be removed.
During existence of a source, a strong reference between an event and a listener prevents a listener from being garbage collected. However, associating an event with a listener using a strong reference can cause unwanted memory usage, i.e., memory leaks.
By employing a weak reference between a source and a listener, allows a listener (and associated information) to be garbage collected at the termination of a process. One approach to the problem is looking for weak references on the listener side, and upon detection of a weak reference, the listener can be collected even though the event source may remain for future activity for which other listeners currently attached may continue to be attached (e.g., owing to a strong reference) or future listeners may be subsequently attached.